命名是创造性工作
代码生成趋近于零成本时，命名是人类在代码中保留「主权」与「意图」的最后一道护城河 — 它不再是给变量起名，而是雕刻系统由哪些「概念」组成的策略性选择。
编程的本质 · SHAPING
塑造解决方案，而非输入语法
AI 处理 How 时，架构师从「实现者」变成「雕刻家」。
- Slice 切问题：把庞杂业务切成逻辑专注的小块
- Bind 绑定：哪些数据与行为应组成内聚抽象
- Name 命名：用什么词汇能精准暴露真实意图
穿透复杂性 · SCHEMATIC
让代码变成流动的图解
var1 / dataA / process() → OrderLifecycleManager / idempotencyKey
- 结构可见：一眼看出系统由哪些核心概念组成
- 切穿复杂：把堆砌的语法转化为逻辑结构图
- 业务对齐：让解决方案与问题域清晰对应
债务传导节点 · DEBT
命名不当 → 认知债 + 意图债
模糊的命名隐藏了 Reasoning，让推导逻辑彻底丢失。
- 认知债：维护者必须反向推导「为什么这么写」
- 意图债：合同模糊，业务目标随时间漂移
- 幻觉放大：AI 在模糊命名上进一步偏离意图
架构师实践 · NAMING REVIEW
解释权测试：仅凭名字解释职责
「不看实现，仅根据这个类名解释它的职责边界与选词理由。」
- 答不上 = 认知投降：被动接受 AI 的「外部推理」
- 认知分担：AI 出备选方案，人类拍板最终命名
- 发展语言：定义团队的普适语言 (Ubiquitous Language)